Critical Chain
= Critical Chain Method = Critical Chain Method (CCM) concepts where first introduced by a paper written in 1984 by Goldratt (“The Goal” – ed. Gower). The main factor for the success of this ideas is that it finds solutions to the classical problems we encounter once we plan following the Critical Path Method (CPM) approach. CCPM (critical chain Project Management) is basically a mix of the most recent best practices: * PMBOK: Plan & Control. * TOC (Theory of Constraints): Removal of bottleneck to solve system constraints. * Lean: Remove waste. * Six Sigma: Reduce any deviation from optimum solution. The problems Going back to CCM, the main problems it aims to solve are: Over estimating. This is a problem that usually comes up when defining plans. In a few words, since: *estimation are always cut; *details, at the beginning of a project are not always clear; *tasks that have the biggest uncertainty are sistematically over-estimated. We create contingencies, to protect us from the fact that things we don’t know will go wrong. This process is then amplified because estimationa are presented to many stackeholders, at many levels, and often each level put its own contingency so that at the end the project duration (& cost) is usually over estimated. Student Syndrome. This happens in case of long projects or loose schedules: usually people will start working on a task not when planned but when the delivery time will be near. The reasons are linked both to the other issues we are presenting here (multitasking, parkinson law) and simply psychological: people will not start working till they will not fell the pressure. Parkinson’s Law. This is a notorious empirical law (Work expands so as to fill the time available for its completion) in Project Management. In other words if you assign 15 day to accomplish a task that can be done in 10, then it will hardly happen that the work will be completed in 10 day, but magically it will be completed in 15. Evidences of this law are well known to PMs. Bad MultiTasking. When multitasking is not correctly managed, the result is wasting of time. This is another well know issue in real projects: when you assign more that one task to a resource, most of the time you will get inefficiencies, because jumping from one to the other, instead of completing one and then the other is only making the most critical task going late. Handling of early finish. The problem in my opinion has even a theoretical reason in the CPM theory. In a few words, even if we would be able to close a task in advance we wouldn’t be able to get the most out of this. Indeed if the task is not on the critical path, closing it in advance doesn’t give for sure a direct advantage (maybe you get some resources free, but without planning you wouldn’t be able to use them) if on the other side the task is on the critical path, an early closing could not be so relevant (in the sens that we could have other tasks that become critical) and, taking the concept to the limit, we could need of replanning the project or part of it, finding maybe another critical path… In any case CPM doesn’t give a natural way to handle early close in the project tasks, since it doesn’t plan it. Planning with CCM CCM is trying to solve all the issues just present by proposing a new approach to the preparation of the project plan. The key points of this new approach are: * Plans “Resource constrained” i.e. where the available resources are a constraint. * Scheduling according to the “Late Finish” principle and direct definition of the critical path (here called critical chain). * Usage of Buffers (added to specific tasks) so that we are able to avoid slipping in the schedule: ** Project Buffers (PB): Time buffer added at the end of the project (usually 50% of the total duration of the tasks in the critical path). ** Feeding Buffers (FB): Time Buffer added at the end of each sequence of non critical tasks. ** Resource Buffers (RB): Time Buffer used as early warning to show that the resource will be used in a specific. Such alert can be put some days before a resource will actually start working. * Removal of contingency time and cut of the duration of all task of 50%. * Somehow the project becomes like a relay race where the “baton” (project flow) goes from one task to the other, avoiding parallel runs and working only on completing the project, where any early close gives higer probability of an early close of the overall project. Let’s see now how to plan in more detail: Define for each task dependencies and assigned resources Plan backward and “as late as possible” In planning with CCM schedule is done starting from the target date (or from the last task) and adding the other tasks (according to the dependencies) in a backward process. Once we close this phase we get the maximum date according to which we can start working on the project without being late. Please note that in this approach all tasks are added near the completion date. Sometime delaying the work can lead to some benefits, for example we minimize Work in Progress and reduce in initial costs. Solve resources conflicts by eliminating multitasking In case of resource conflict, activities will be delayed or started earlier but will not execute in parallel, with the resource working on both. This means that if two activities use the same resource, they will be in sequence, instead of lasting more and being shared. Obviously the most critical activity will have the higher priority. At the end of the phase we should have for every resource a sequence of not overlapping task assigned. Identify the critical chain Now we should be able to identify the critical path of the project. In CCM this is called critical chain. Cut every task by 50% All tasks will be correctly estimated (even better estimated using statistical methods) and then all estimation will be halved. Introduce Buffers After eliminating the resource contemptions and the multi-assignement practice, the introduction of buffers is the second new idea of CCM: we introduce buffers, i.e. period of time that protect the project from the fact that if a deliverable is going to be late, the overall project will not suffer this delay. CCM uses buffers in critical point of a project and among two or more projects (multiproject environment) with the idea of making the project steadier, against changes in it. Indeed without buffer, every change is going to modify the plan. it is exactly the role of buffer to stabilize the project, acting, somehow, as contingency. As written up we use three kind of buffer: * project buffer – We don’t add buffer to the tasks of the critical path. We only add an unique final buffer that should take in account all the uncertainties within the tasks.This buffer should be around 50% of the duration of the critical chain. * feeding buffer – these buffers are added at the end of chains of tasks, that are not part of the critical path, before connecting to critical tasks so that we take in account for uncertainties in task not critical. * resources buffer – These are buffers added as “wake-up calls” to alert resources so that we are sure that they will be ready to work on task of the critical chain. At this point the plan is complete. For comparison below you can see the picture of the same project as worked out by MsProject by using a resource levelling. Monitoring the project Monitoring a project where CCM has been adopted needs to be done using techniques different slightly different from the traditional ones. All tasks have a duration which is 50% of the original one, so it doesn’t make sense to monitor if the task is closed within the planned date and to handle like “delay” if a milestone was missed. What makes sense to do, is monitoring the buffers that were created during the planning phase. As a matter of fact it’s possible to build simple graphs that show the way buffers are consumed as the project goes on. If the consumption speed of our buffers is low, we can assume that the project is “on target”, if on the other side the speed is so fast that we can forecast that we will not be able to close the project without using more buffer that what we planned, in this case we need to perform some corrective actions, in the worst case to develop recovery plans or to completely replan the project. CCM in multi-project environments Working in multi-project environment simply amplifies the multitasking problems: * Multitask work generates inefficiencies * Links and Constraints number becomes bigger, making complex to manage project changes * Focus decrease CCM approach multi projects with the idea to maximize the capability of completing project of a structure, based on the priorities and on the constraints coming from the resources. The way to do it is simple: Schedule the single projects, according to CCM Solve all resource contention problems, working most on the resources most used among the projects and assuming that is the availability of resources that determines the speed of the project. Goldratt defines these resources (the ones around which project are scheduled) as “drum resources” Define the start of the projects according to priorities and boundaries. With these principles we should be sure thaat projects are scheduled based on constraintes and capacity of the organization. The final effect will be the one of a better resource usage and the delivery of critical projects in advance to what happens using traditional schedule methods. Following an example of schedule in traditional way and the same example worked out by using CCM: Conclusion Project control I’m quite positive towards CCM, especially in planning for software development, however one of the areas that i still don’t feel comfortable is the project control. I think CCM still needs to develop specific tools in this subject. According to the literature, project analysis should be done by means of: * Reporting on buffer usage. Comparison of completed task in the critical chain agaist percentage of buffers used, in a way to estimate completion date of the project Checking of consumption speed of buffers (or as percentage or as absolute days). Anyway, I think that to control projects only by analyzing buffer consumption, is not such a strong technique, especially if compared to what is possible to do with CPM (see for example the basic EVM). As a matter of fact we should dig into this area and maybe develop some stronger (mathematical) tools. If then we move to the area of project costs, we should find a way to expand the concept of buffer and introduce the “cost buffer”, in a way to link the analysis of the cost of a project to the normal buffer, otherwise cost analysis will be too much random. * Risk Analysis and Buffer. In some articles we find that the analysis of buffer consumption can also be linked to risk analysis, however even in this subject I would follow a cautious approach. At this level of maturity, we shouldn’t try to integrate risk management within the buffer analysis, but we should keep it separated. Do we estimate correctly cutting everything at 50%? Cutting estimation at 50% is a statement that we should analyze better. In the net it is possible to find some articles about this, however in my opinion not all treat the matter clearly as 60% o il 40% could be good as well. As some articles suggest, I think it is important to use a series of estimation and statistical methods to find the duration of the tasks. Once we have this estimation it is possible to cut the activities in a way that will give us 50%,60% or any other well determined percentage of likelihood of task completion. In this way we would also be able to give a statistical meaning to our plan, as it is possible to understand by looking at the next picture: CCM compared to al CPM Speaking of software development, CCM, especially at the beginning, can be used with advanced teams that are aware of risks and characteristics of it and in specific cases (when task are not fixed duration and don’t involve an high number of resources). As a matter of fact we have a new approach that gives a lot of advantages but deserves some attention points: looks easier but it’s more complex Plan with CCM is more complex than planning with CPM. Even tools that we may use are “calibrated” on CPM, so a bigger work is needed. You need to know better your project and its characteristics First you need to have cleat tasks, durations, links and most of all resources (usually not so clear at the beginning). More it is necessary move from one approach where estimation is unique to an approach where estimation should be build on a statistical basys. I think statistics are much more important in CCM than in CPM: here the estimation process is quite important to understand how we approximate buffers estimation and how we handle them. Indeed buffer duration needs to be estimated as much correct as possible, since it is from this estimation that we should get the theoretical maximum duration of the project. CCM should be used instead of CPM only when more convenient Not all project can be managed in a natural way with this methodology. In my opinion CCM is best suitable for projects where tasks don’t have fixed duration. For example in a gap analysis project where meetings are the core of the project, the best way is to use the CPM, since usually it takes a lot of time to schedule all meetings and it is not easy to move them, in case of some delay or early finish of the meetings. I think we should be able to find a trade-off in the projects so that we can manage tasks in the best way: we need to fix some criteria to understand what planning method is the more convenient. Personally I would follow CPM in case there aare many fixed duration activities and many resources involved, while I would use CCM in projects with a few resources and activities that depend more on the amount of work Maybe using a mixed approach, where all the project is managed using CCM (or CPM) and some specific subprojects are managed with CPM (or CCM) could bring some improvement, but this need to be checked. Regardless all this issues i think that CCM is a good planning method and that it make sense to exploit it both in “real” (by starting with small software projects project, where there is a basic uncertainty on the duration) both on the theoretical side, by developing better tools for managing and controlling the project. Let me know your opinion